Context Conflict Resolution and Automatic Context Source Maintenance

ABSTRACT

Techniques are disclosed for detecting and resolving conflicts in context information from various sources. That information may be used to automatically update one or more context sources and/or to validate or invalidate (until further notice or for a period of time) input from one or more context sources. Or, the updates can be made in response to the user&#39;s instructions. Rules are used in preferred embodiments to dictate the conflict resolution approach for individual users. Updating the context source is particularly useful when the source is an electronic calendar. Updates that may be made to the calendar include adding, deleting, or changing scheduled events and/or working hours. Invalidating data from a context source is particularly useful for lost, forgotten, misplaced, or loaned devices. Marking data from a context source as valid is preferably done when harmony among several context sources is detected. Context suppliers may be notified of errors or discrepancies in their context data.

RELATED INVENTIONS

The present invention is related to the following commonly-assigned U.S.patents: U.S. Pat. No. 6,988,128, titled “Calendar Events andCalendar-Driven Application Technique” (Ser. No. 09/670,844); U.S. Pat.No. 6,640,230, titled “Calendar-Driven Application Technique forPreparing Responses to Incoming Events” (Ser. No. 09/671,001); U.S. Pat.No. ______, titled “Calendar-Enhanced Awareness for Instant MessagingSystems and Electronic Status Boards” (Ser. No. 09/941,045); U.S. Pat.No. ______ (Ser. No. 10/245,156, filed concurrently herewith), titled“Keeping Working Hours and Calendar Entries Up-to-Date”; and U.S. Pat.No. ______ (Ser. No. 10/245,200, filed concurrently herewith), titled“Predicting and Adjusting Users' Working Hours and Electronic CalendarEvents”. The disclosures of these related inventions are herebyincorporated herein by reference. p

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to computer systems, and deals moreparticularly with methods, systems, and computer program products forresolving context conflicts (for example, a person's electronic calendarshows that he has a meeting scheduled in a particular location, but abadge reader or tracking device indicates that he is elsewhere), andprogrammatically updating the context source, invalidating the source(at least temporarily), or notifying the supplier of contextinformation.

2. Description of the Related Art

The term “context service”, as used herein, refers to an automatedservice that provides information about user context. Context servicesare known in the art. Examples of context services include a systemreferred to as “Owl” in “Issues for Context Services for PervasiveComputing”, M. R. Ebling et al., in Proceedings of the Workshop onMiddleware for Mobile Computing 2001, Heidelberg, Germany (November2001), and the Context Toolkit from Georgia Institute of Technology.Refer to http:/www.cs.arizona.edu/mmc/Program.html andhttp://www.cc.gatech.edu/fce/contexttoolkit for more information onthese context services.

A context service may receive context information from a variety ofsources, including electronic calendars, location sensors, and othersensors such as badge readers and motion detectors. The context servicethen provides the context information to one or more applications,allowing those applications to be “context aware”. Examples ofcontext-aware applications include the following: (1) a notificationsystem that sends notifications to a pager or other device; (2) alocation-based service that provides location-specific information (suchas traffic data) to a user, depending on the user's context; and (3) atravel-time calculator that uses a person's current location todetermine when the person will arrive at another location.

FIG. 1 shows a high-level view of a context service of the prior art.The source of the context information is represented at the left withexamples such as an electronic calendar system 100, a cellular phone110, and a badge reader 120.

The electronic calendar system 100 may be a product such as LotusNotes®, Microsoft Outlook® 2000, or Microsoft Exchange, or it may be anadvanced calendar system such as that disclosed in the related patents.(“Lotus Notes” is a registered trademark of Lotus DevelopmentCorporation and “Outlook” is a registered trademark of MicrosoftCorporation.) A calendar system provides context information such as acalendar owner's scheduled events, and optimally the location ofmeetings and other events, preferred means of contact during certainevents, and so forth.

A cell phone 110 may be used to provide context information about itsuser such as the user's physical location, and the cell phone may alsoprovide device information such as its telephone number or serialnumber.

A badge reader 120 can be used to provide information about theidentification of people who have passed their badge through the reader,as well as the time and location at which this occurred. “Smart badges”,on the other hand, function as transmitters that provide continuouslocation information without requiring explicit action at a badgereader.

Other sources of context information 130 might include a motion detectorin an office building. For example, an organization might place motiondetectors in offices or conference rooms in order to automatically turnoff the lights when no movement has been detected for a configurabletime interval. Executing application programs may be capable ofdetermining a level of awareness about their users (e.g., whether theuser is logged in, logged off, inactive, and so forth) and may beanother source of context information.

Each context source typically has a context receiver, shown generally at140 of FIG. 1. A context receiver receives, analyzes, and interpretsinput from the context source, and then makes this information availableto applications via the application programming interface (“API”) 150.An example of context interpretation is the translation of geographicalcoordinates into a street address or a building and office number. Anexample of analysis is the reduction of frequently-transmitted locationdata into more meaningful events. That is, most applications don't needor want to know if a person moves within his office or a meeting room,but would like to be informed if the person moves to another room orleaves the building.

The granularity of context information provided to an application 160,170 may be determined in a variety of ways, according to the prior art.For example, a configurable number of events might be sampled during aconfigurable time interval. Values of these configurable parameters mayvary depending on factors such as a user's location. Thus, anapplication might receive less granular movement information for aperson who is driving down the highway and more granular information forthat same person if he is moving within a building.

Context sources can be categorized into two basic types, updateable andfixed, as shown at 200 and 210 in FIG. 2. The updateable context sourcesare sources such as electronic calendars, where the context can bechanged at the source to update or correct the context information.(That is, if a user's calendar data provides incorrect contextinformation about the user, then the calendar can be modified.) Fixedcontext sources are devices such as cell phones with embedded globalpositioning system (“GPS”) receivers that are not designed to beadjusted at the source. As shown in FIG. 2, a plurality of contextsources (represented by the basic types 200 and 210) may be used in acontext-aware system, each typically sending its context information toa context receiver, shown generally at 220.

This context information is gathered for and provided to context-awareapplications 160, 170. The applications can use the context directly ormay use the services of a mediator (shown in FIG. 2 at 230), which canreceive multiple sources of context information and provide consolidatedand more accurate context information to the applications. For example,the same or related context information may be sensed by multipleredundant sensors. By comparing the different sources, the mediator canprovide more precise context information to the applications. Forexample, if there are three redundant sensors, a voting procedure mightbe used to select one of them. Or, algorithmic comparisons might be usedto reject the source with the largest variation among them.

Electronic calendars often contain a wealth of information about theirowners. For example, an individual may use an electronic calendar tomaintain information about his work schedule, his meetings and otherappointments, his vacation and business travel plans (including when hewill be away, which flights or other transportation he will use, wherehe can be reached while away, who he may visit while away, etc.), phonecalls that need to be made at particular times, and so forth.

Electronic calendars may be accessed by people and/or by applications.Calendar data can be used to automate tasks and to inform others aboutthings such as whether the calendar owner is currently available, or isout of the office on business, and so forth. For example, the relatedinvention titled “Calendar Events and Calendar-Driven ApplicationTechnique” (U.S. Pat. No. 6,988,128) uses calendar data to automatevoice mail greetings, among other things. It does this by analyzingcalendar data, including a person's scheduled working hours and otherscheduled events. The related invention titled “Calendar-EnhancedAwareness for Instant Messaging Systems and Electronic Status Boards”(U.S. Pat. No. ______) discloses techniques whereby calendar data isused as input to instant messaging (“IM”) systems and electronic statusboards. With the increasing use of calendar data, such as disclosed inthese related inventions, it becomes more important to keep calendardata up-to-date and accurate.

Occasionally, a person's electronic calendar may not accuratelyrepresent his current status. For example, if Lisa is scheduled to be ina meeting from 3 p.m. to 5 p.m. on Friday, but she becomes ill at lunchtime and goes home for the rest of the day, her calendar will likelyreflect that she should be in her office until 3 p.m., and then in theconference room where the meeting is scheduled for the next two hours.In days past, it was the responsibility of a human administrativeassistant or secretary to tend to employees' calendars, taking care ofthese types of schedule updates. Very few employees have this luxurytoday, however, and instead are responsible for maintaining their ownschedules using electronic calendars. When a calendar user has tomanually update her electronic calendar for every variation in herworking hours and the meetings and other events which occupy thoseworking hours, it is likely that some updates will not be made. As aresult, accesses to the user's calendar data will provide incorrectinformation about her availability. Accesses may be made by individualsand/or by applications. For example, suppose Ellen is attempting toschedule a last-minute department meeting with all of her co-workers,including Lisa, for Friday afternoon between 2 p.m. and 3 p.m., andaccesses their electronic calendars to see whether they will be in theoffice. Based on Lisa's inaccurate calendar information, Ellen willmistakenly believe that Lisa can attend.

With reference to the related invention titled “Calendar Events andCalendar-Driven Application Technique” (U.S. Pat. No. 6,988,128), if anautomated voice mail system according to this related invention takes anincoming call to a calendar user's phone number and generates a messagefor the caller based on that user's inaccurate calendar data, the callerwill be incorrectly informed as to the user's availability. In somecases, this is merely a nuisance. On the other hand, if someone needs tolocate the calendar user for an important business matter or for apersonal emergency, the incorrect information can have significantconsequences.

In general, when an electronic calendar user's actual schedule does notconform to the information that has been provided to the calendarsystem, individuals looking at the calendar can be misled andapplications that rely on calendar data for input cannot functionoptimally. Similarly, when applications other than electronic calendarsystems are using context information that is incorrect, thoseapplications cannot perform optimally. Accordingly, what is needed areimprovements that enable context information such as calendar data tomore accurately reflect a user's actual status.

SUMMARY OF THE INVENTION

An object of the present invention is to provide improved techniques forkeeping context sources such as calendar data accurate by detecting andresolving conflicts in context information.

An additional object of the present invention is to provide techniquesfor adding, deleting, and/or changing calendar entries to resolveconflicts in a calendar user's status.

Another object of the present invention is to provide techniques foradjusting a user's working hours to resolve conflicts in a calendaruser's status.

A further object of the present invention is to provide techniques forinvalidating (until further notice or temporarily) a context source toresolve conflicts in a user's status.

Another object of the present invention is to provide techniques forindicating that a context source is valid (until further notice ortemporarily) when conflicts involving that context source have beenresolved.

Still another object of the present invention is to provide techniquesfor programmatically notifying a context supplier of conflicts incontext information.

Yet another object of the present invention is to make electroniccalendars more useful.

A further object of the present invention is to increase the accuracy ofinformation available from context sources, including electroniccalendars.

Other objects and advantages of the present invention will be set forthin part in the description and in the drawings that follow and, in part,will be obvious from the description or may be learned by practice ofthe invention.

To achieve the foregoing objects, and in accordance with the purpose ofthe invention as broadly described herein, the present inventionprovides systems, methods, and computer program products for detectingcontext conflicts and automatically resolving the conflicts. In oneaspect, this technique comprises: gathering context information from aplurality of context sources; determining whether a conflict exists inthe gathered context information; and if a conflict is determined toexist, resolving the determined conflict by applying a set of rules andperforming action(s) specified by one or more of the matching rules.Preferably, the rules are checked by a rules system to ensure that theydo not conflict with each other and cause the conflict resolution systemto go into a loop. Preferably, gathering of context information istriggered by detecting a context change. This technique may furthercomprise ignoring, when gathering context information or determiningconflicts, any context information marked as invalid.

User interaction may optionally be included when determining how toresolve a detected conflict.

In one scenario, performing the actions may further comprise updating acontext source, which may (for example) be a user's electronic calendar.The update to the user's electronic calendar may comprise one or more ofadding, deleting, or changing events or working hours on the calendar.

In another scenario, performing the actions may comprise invalidating acontext source. The invalidation may be effective until further notice,until an ending time, or for a duration of time. Apreviously-invalidated context source may be returned to a valid stateupon detecting harmony among the context sources.

In yet another scenario, performing the actions may comprise notifying acontext supplier of the determined conflict.

The determination of conflicts may, in some cases, determine that aplurality of conflicts exist in the gathered context information, inwhich case the plurality of conflicts are resolved by applying the setof rules and performing action(s) specified by one or more of thematching rules.

In another aspect, the present invention provides techniques fordetecting harmony in context information. Preferred embodiments of thisaspect comprise: gathering context information from a plurality ofcontext sources; determining, using the gathered context information,whether harmony exists among multiple ones of the context sources; andif harmony is determined to exist and any of the context sources aremarked as invalid, applying a set of rules to determine whether thesources marked as invalid should be marked as providing valid contextinformation.

Techniques of the present invention may also be used advantageously invarious methods of doing business. For example, a context conflictresolution system providing the advantageous features disclosed hereinmay be marketed to users under various revenue models, including monthlysubscriptions (or other periodic subscriptions), pay-per-use, etc.

The present invention will now be described with reference to thefollowing drawings, in which like reference numbers denote the sameelement throughout.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 provides a high-level overview of a context service according tothe prior art;

FIG. 2 provides a high-level overview of components of a context serviceusing a mediator to mediate context information from multiple sources,according to the prior art;

FIG. 3 provides a high-level overview of components that may be used bypreferred embodiments of the present invention; and

FIGS. 4-7 provide flowcharts illustrating logic that may be used whenimplementing preferred embodiments of the present invention.

DESCRIPTION OF PREFERRED EMBODIMENTS

The present invention defines improved techniques for use with contextsources such as electronic calendars, whereby calendar data or othercontext information will more accurately reflect a user's context.Conflicts in the user's context are detected and resolved, and thecontext source may then be automatically updated. When the contextsource is a user's calendar, the updates may comprise one or more ofadding, deleting, or changing scheduled events and/or working hours.Alternatively, the context source may be invalidated (at leasttemporarily) to resolve the conflict. As yet another alternative, anotification may be sent to the context supplier, informing the contextsupplier of the conflict. Combinations of these actions are alsopossible (such as invalidating a context source and notifying thecontext supplier). Rules are used in preferred embodiments to specifyhow the resolution of conflicts should be carried out, as will bedescribed. A set of rules that is applicable to all users or groups ofusers within an organization may be used; in preferred embodiments,individual users are also allowed to specify rules. The user may beprompted for input before context resolution actions are taken, and maybe allowed to confirm or reject impending actions.

Using the techniques disclosed herein, electronic calendar users areable to keep accurate working hours and scheduled events on theircalendars much more easily and efficiently, without having to manuallydetect conflicts in their context and without having to manually resolvesuch conflicts. Because programmatic means are used, as disclosedherein, it is much more likely that the user's calendar will accuratelyreflect his working hours and his scheduled events. This improvedaccuracy will be of benefit to other people viewing the user's calendaras well as to other systems/applications that analyze or use calendardata. Similar advantages may be realized with updateable context sourcesother than electronic calendars.

The term “calendar data”, as used herein, refers to information of thetype used by electronic calendars. In preferred embodiments, thisinformation comprises calendar entries (referred to equivalently hereinas “calendar events”) as well as other information such as user profilesand user preferences. User preferences may be used to indicate how aparticular calendar owner's calendar entries should be interpreted, suchas the user's preferred mode of contact (e.g., by phone, by pager, etc.)during various types of scheduled events, how often the user checksvoice mail, and so forth. User profiles store information such as thecalendar owner's working hours, the default time zone to be applied tothe user's calendar, and optional profile-specific preferences (such asa pager number with which a user can be contacted during the workinghours defined in the particular profile).

It should be noted that while preferred embodiments are described withreference to modifying electronic calendars, this is by way ofillustration and not of limitation. The techniques disclosed herein mayalso be used advantageously to reflect conflict resolutions in othersystems.

Preferred embodiments of the present invention leverage a contextservice. Context services of the prior art were described above withreference to FIGS. 1 and 2. FIG. 3 shows a high-level view of componentsthat may be used in an embodiment of the present invention. In additionto providing context data to application programs 160, 170, the contextreceivers 220 used with preferred embodiments of the present inventionalso provide context data to a special application called a “monitor”that checks for conflicts. The monitor is shown at 340 of FIG. 3. Inpreferred embodiments, the context receivers 220 provide meaningful datato this monitor 340. “Meaningful” refers to information that a contextreceiver has interpreted and consolidated from the input it receivesfrom the context source. Thus, as an example, when a context receiver isprocessing a user's physical location, it is preferably configured withtolerance parameters that determine when a “meaningful” change in theuser's location has occurred. In this manner, the monitor 340 (as wellas other context-consuming applications 160, 170) is shielded from beingflooded with information that is not useful.

The monitor 340 used with preferred embodiments is augmented asdisclosed herein to perform context conflict resolution and automaticcontext source maintenance, in addition to checking for conflicts. Thismonitor may operate as part of a context service, or independently fromthe context service. The monitor preferably uses a set of rules that iscustomizable by organizations and/or individual users. The monitor mayreceive input from context receivers via the API 150 directly or via amediator 230, from users as shown at 330 (e.g., asynchronously or byquerying a user for input and receiving the user's reply), and/or fromutility services 360.

Context-aware applications rely on accurate context information. Animplementation of the present invention may update a context source, asshown in FIG. 3 where an adjustment 300 is made to updateable contextsource 200. For example, a context conflict on a user's calendar mightbe resolved by deleting a scheduled event. There may be cases where itis not appropriate to update the context source (such as when thecontext source is fixed, illustrated by source 210 in FIG. 3). For thesecases, the context may be resolved by adjusting the context data, asshown at 310 in FIG. 3. When the monitor determines that a contextsource is in error, a notification may be sent to the context supplier,as shown at 350.

Along with the actual context information, context services can provideassociated information about the validity of the context informationthey provide. Preferred embodiments of the present invention may makeuse of this validity information to invalidate a context source for aperiod of time, letting the interested applications know that thecontext from this source may be incorrect. For example, when used with anotification system that sends notifications to a pager or other device,setting the pager's context to invalid might result in temporarilyholding a page (rather than sending it to the pager) or in sending it toanother device whose context is valid. As another example, when alocation-based service sends information to a device, the informationwould not be sent to a device whose context is marked invalid.

Invaliding a context source is preferably done by setting an associated“validity” attribute or field to “invalid”. Preferred embodiments alsoprovide an ending time or duration for the invalid status, or theinvalid status may be allowed to persist until further notice. Contextdata marked “invalid” will generally be ignored by applications;however, applications can still access the context information andcertain applications, such as context logging applications, may stilluse the information. This validity information is preferably availableto all users of the context information, including mediators andmonitors. The monitors may, for example, use context information marked“invalid” to decide when the information may again be valid.

Just as conflicts in context information can be used to set a contextsource to “invalid”, harmony in context can be used to reset the sourceto “valid”. For example multiple context sources may indicate that aperson is in his office while his cell phone location indicates that heis at his home. This conflict can be used to mark the cell phone contextinformation as “invalid”. Should the cell phone location once again comeinto harmony with the other context sources, this could indicate thatthe person now has the cell phone in his possession and that the cellphone location can now be marked as “valid”.

There are many potential sources of context information. By way ofillustration but not of limitation, the discussion below will use threecontext sources; however, embodiments of the present invention mayhandle a variety of other forms of context information. The three formsused herein for illustration are: (1) calendar-based context; (2) cellphone-based location information; and (3) smart badge locationinformation.

A context receiver for calendar-based context can indicate various typesof status information about a calendar owner. For example, a user'scalendar typically specifies when he is in the office, out of theoffice, busy (e.g., in a meeting), on vacation, and when it is outsidethis user's working hours. In some cases, calendar-based context canalso indicate a user's location (i.e., as specified on his calendarentries).

A context receiver for cell-phone-based location information can providelocation, and may also provide information about the user's speed anddirection of travel. This information might be used to detect conflictssuch as impossible or improbable physical locations for a user. Forexample, suppose that Mary is scheduled to participate in a meeting inconference room A123 in 5 minutes, according to her electronic calendar.Further suppose that Mary's cell phone indicates that she is 30 milesaway and is moving at 60 miles per hour. Mary's calendar and her cellphone thus provide conflicting context data, and the monitor mayconclude (based on the rules) from its input sources that Mary is eithergoing to be late for the meeting, or is not going to attend the meeting.The monitor may make use of various types of systems or services as itevaluates rules (as shown in FIG. 3). One example is a travel timecalculator. Travel time calculator services are known in the art. Thisservice might be provided with 2 locations, such as the conference roomand Mary's current location; or, it might be given additionalinformation such as speed and direction of travel. An expected traveltime can then be calculated. Mary might have a rule that says “If I amgoing to be at least 10 minutes late for a scheduled meeting, then pageme”.

A context receiver for smart badge location information can track aperson's location within a set of buildings. This context receiver canprovide events/notifications when a person enters or leaves one of thebuildings and also when the person moves from one room to another in abuilding.

The input the monitor receives for calendar-based context, cellphone-based location context, and smart badge-based location context maybe obtained, as needed, by one or more of the following techniques: byquery when needed, by periodic polling, or by events.

In addition to these inputs from the context receivers 220 (typicallyreceived via the context server API 150 or via a mediator 230, as shownin FIG. 3), the monitor 340 preferably has access to other inputs anddata. These include, but are not limited to: the current time and date;owner actions; rules; utility services 360; context change and ownerinteraction history; and timer expiration events.

The current time and date may be useful for looking at a user's calendardata. The rules applied when the monitor is analyzing/resolvingconflicts may also be time-sensitive, and the current time and date maybe used for analyzing these rules.

The monitor may also store or access a history (say for the last 24hours) of all changes to all the context sources it monitors, as well asqueries to users and their replies. This information can be used, forexample, in the case where a set of users report that the same locationservice is giving bad information. This data could be used to determinethat the location service is having problems, rather than the set ofusers, and a notification may be sent to the provider of the locationservice (represented in FIG. 3 by context supplier 350).

In preferred embodiments, when a user's context information changes, themonitor 340 checks for conflicts in that user's context. The monitor hasinputs from a number of sources (as discussed above with reference toFIG. 3); preferably, the user is able to specify which context sourcesare used. Given an input, the monitor processes rules that specifyactions, all of which are discussed in more detail below. For example,if the user's calendar indicates that he has a different scheduled eventthan he had five minutes ago, or a badge reader has recorded himentering the office building, then these context changes trigger anautomated evaluation of other context information for this user. Basedon the context change and whether there is a conflict, the monitorapplies a set of rules and takes actions. These actions can be used toperform many different types of updates, such as updating the user'scalendar information and/or to invalidate data from other contextsources for a period of time. Or, the action might be to notify thecontext supplier of the conflict. As an example of updating the user'scalendar, if the conflict arose because of incorrect information on thecalendar, then the conflict might be resolved by deleting or changing anevent. As an example of invalidating data from a context source, supposethe user's cell phone indicates that he is in the cafeteria of Building123, but a badge reader in Building 678 (located several miles away fromBuilding 123) has just detected this user's badge. The user may haveforgotten his cell phone when he finished lunch, in which case anappropriate action is to ignore the cell phone location (i.e., the cellphone as a context source) for some period of time. As an example ofnotifying the context supplier of the conflict, suppose that a user'scell phone and smart badge are with the user but that the contextreports one of them elsewhere. In this case, the service provider of thecontext information can be informed that it has a problem with itssystem.

FIG. 3 shows the monitor 340 interacting with users 330. User actionsinclude, by way of example, instructions from the user to ignore acontext source for some time period, or instructions from the user toupdate the context source (e.g., to delete a conflicting event from hiscalendar). Instructions from the user may be obtained in many differentways, and an implementation of the present invention may support one ormore such methods. For example, an embodiment of the present inventionmight send a message as a page to a 2-way pager, and the user's responsemight be numeric data that is used to select from among multiplepredefined actions (such as “press 1 to delete the conflicting calendarevent”, “press 2 to invalidate the cell phone as a context source”, andso forth). In this example, instructions (derived from the rules) wouldbe entered simply by pressing the proper key. The monitor is thenresponsible for correlating the response with the proper outstandingquery, so that it can properly interpret the response. Alternative waysof providing user instructions include a voice-activated commandprocessor or voice response unit; a graphical user interface (“GUI”)that displays a pop-up asking the user to select (or otherwise provide)an appropriate response; a touch-sensitive screen with which the usercan select a response; and so forth.

Timer expiration events (along with information about the event thatcaused the timer to be started) may be useful in many differentscenarios, such as when an event is ambiguous. For example, suppose Fredis detected leaving the building at 11:15 a.m. but there is nocorresponding event on his calendar. Fred might be leaving the buildingfor a smoking break. If Fred normally takes 15 minutes for such breaks,he might define a rule that sets a “smoking break” timer for 15 minutes.If Fred reenters the building before the timer expires, the timer issimply canceled. However, if Fred does not reenter the building beforethe timer expires, then maybe Fred is not taking a smoking break afterall. A rule might specify that if it is between 11:00 a.m. and 1:00p.m., a message should be sent to Fred's cell phone, asking him whetherhe would like the monitor to schedule a lunch break on his calendar.(The duration of this lunch break might be determined by the rule, or byanother rule, or could be determined by asking Fred to use the keys onhis phone to signal the expected ending time or the expected duration ofhis lunch break.) Or, a rule might specify that a lunch break is to beautomatically added to Fred's calendar, without requiring his input.

The rules are used to apply the judgment or decisions in the monitor.The rules used by a particular implementation may vary widely, dependingon what context data is available, what the supporting organization(such as a corporation) wants, and what the individual user wants. Therules can change as the supporting organization and/or the user adds,deletes, or modifies them. The rules therefore allow organizations/usersto personalize their own conflict detection and resolution techniques.

Preferably, all rules have a default action. In the simplest case, thedefault action is to do nothing.

If a rule includes the starting of a timer, the rule preferably alsoincludes the specification of an action to take if a user response orother event doesn't cancel the timer before it expires. For example,with reference to the previously-described scenario of Fred leaving thebuilding and starting a 15-minute timer, the action upon timerexpiration might be “update the calendar by adding a lunch event”.

Conceptually, the rules are modeled after the instructions that a personmight give to an administrative assistant or those which the assistantmight learn through observation. Several rules will now be provided byway of illustration. (Note that this set of rules contains someoverlapping conditions with different corresponding actions. These rulesare intended to show different possibilities, rather than a set of rulesthat might be applied for a particular individual.)

-   -   If the current time is after 4:00 p.m., and there are no        off-site events on my calendar, and my smart badge indicates        that I have left the building, then update my calendar to        indicate that I have left for the day.    -   If the current time is between 1:00 p.m. and 4:00 p.m., and        there are no off-site events on my calendar, and my smart badge        indicates that I have left the building, then set a 10-minute        “end of working hours” timer.    -   If my 10-minute “end of working hours” timer expires before I        reenter the building, then update my calendar to indicate that I        have left for the day.    -   If the current time is between 11:00 a.m. and 1:00 p.m., and        there are no off-site events on my calendar, and my smart badge        indicates that I have left the building, then add a 1-hour lunch        event to my calendar.    -   If my smart badge indicates that I have entered the building,        and my cell phone is located outside the building, then set the        validity attribute for my cell phone location context to “ignore        until 5:00 p.m.” and notify me that my cell phone is being        ignored since the phone is not with me. (This rule might be used        to account for cases in which the user forgot to bring his cell        phone to his office.)    -   If I have a meeting scheduled for the current time, but my smart        badge indicates that I am not in the meeting room, then send a        message to my pager to remind me of the meeting and provide the        following response options:

1) I plan to attend (the system will take no other action)

2) Inform the other participants that I will be late (this will invokeanother service to send the notice)

3) Delete the event from my calendar and inform the other participantsthat I will not attend.

-   -   If my smart badge indicates that I have returned to my office        prior to the ending time of a meeting scheduled on my calendar,        then change my calendar to indicate that I am available by        updating my calendar, setting the actual end of meeting time to        the current time.    -   If my smart badge indicates that I have arrived in my building,        and my calendar indicates that my scheduled working hours have        not yet started, then update my calendar to change my working        hours to start at the current time.    -   If it is 30 minutes past my scheduled end of working hours, and        my smart badge indicates that I am still in the building, then        send me a message asking me how long I plan to stay.    -   If my smart badge locates me in my office, but my cell phone        location changes from my office to the parking lot, then disable        my smart badge as a context source until the start of my next        scheduled working hours and notify me that my badge is being        ignored since the badge is not with me. (This rule might be used        to account for cases where the person forgets to take his badge        when he leaves his office for the day.)

As demonstrated by these sample rules, the actions to be performed as aresult of the rules can vary widely. In general, possible actionsinclude (with each action being specific to a particular user, inpreferred embodiments):

-   -   add, delete, or change calendar events;    -   update an updateable context source;    -   add, delete, or change working hours intervals;    -   inform the owner of the calendar or other context information of        a detected discrepancy or event, and ask what action to take        (optionally setting a timer to control how long to wait for the        owner's response);    -   in a context receiver, set the context information's validity        attribute to “invalid” or “valid” for a time period;    -   notify the supplier of context information that there is an        error in the data being provided;    -   initiate a task; and    -   set or cancel a timer.

As an example of setting the validity attribute for a context source to“invalid”, if a conflict is detected between Allen's smart badge and hiscell phone (perhaps because Allen left his location-sensing cell phoneat home), Allen might indicate that the context receiver for locationdata from his cell phone should set the validity attribute for this cellphone to invalid until 6:00 p.m. (when Allen expects to be back home).Given this same conflict between cell phone and smart badge, anotheruser Lynn might specify a rule that resolves the conflict in acompletely different way. For example, Lynn might realize that shefrequently loses her smart badge, but that she always has her cellphone, and thus in her case, her rules specify that her cell phoneshould “win” the conflict with her smart badge.

When querying the user for whom a conflict was detected, many differenttechniques might be used, such as displaying a pop-up window on theuser's workstation, sending the user a 2-way page, or initiating atelephone call to the user. Preferably, regardless of the querytechnique, the query provides a brief description of the conflict andgives the user predefined options from which to select. For example, amessage might say, “Your smart badge locates you in your office, butyour calendar has a meeting scheduled at this time in Room 310. Press 1to ignore your smart badge until further notice, press 2 to remove themeeting from your calendar, or press 3 if you want no action taken.”

Referring now to FIGS. 4-7, flowcharts are provided that depict logicthat may be used to implement preferred embodiments. As shown in FIG. 4,the general mode of operating the present invention comprises detectinga context change (Block 400), such as receiving input that the user isnow in a new location or that a different event is now scheduled on theuser's calendar, and Block 405 then gathers available context input fromcontext receivers.

Block 410 checks to see if the context sources are in harmony. If so,then Block 415 applies rules that are applicable to this user. Inapplying these rules, Block 415 may make use of utility services (asillustrated at 360 in FIG. 3) such as a travel time calculator and/or alocation service. Block 420 performs the unit(s) of work to carry outaction(s) specified by the matching rule(s). (This process is describedin detail with reference to FIG. 7, below.) These actions may includeupdating an updateable context source (such as an electronic calendar),validating or invalidating one or more context sources (eithertemporarily or until further notice), or notifying a context supplier.In preferred embodiments, all rules applicable to this user areevaluated, and the actions from each matching rule are performed. Inalternative embodiments, the process of applying rules may be haltedwhen a first matching rule is encountered, and the actions for that ruleare then carried out.

Block 425 is reached following completion of Block 420, or when theharmony was not detected in Block 410. Block 425 ignores contextinformation from sources whose validity attribute is set to “invalid”for the current time.

Block 430 then determines whether a context conflict exists. To avoidcreating false conflicts, certain context information (such as locationinformation) should not be interpreted too precisely. For example,having the smart badge and cell phone location information within 20feet of one another should not be interpreted as a conflict. Thisdistance is preferably configurable and may vary for different physicallocations as well as with different context sources.

If no conflict exists, then the process of FIG. 4 exits. Otherwise,Block 435 applies rules that are applicable to this user and Block 440performs the unit(s) of work to carry out action(s) from the matchingrule(s), as described above with reference to Blocks 415 and 420. Theprocessing of FIG. 4 then ends for this invocation.

FIG. 5 shows logic that may be used to process explicit user input. Thisis generally a response to a query from the monitor, but may also be anasynchronous request from the user. The user's input is received (Block500), and Block 505 then checks to see if this response corresponds to aquery from the monitor. If so, then Block 510 correlates the responsewith the outstanding query and decodes it. That is, the response isinterpreted based on any correlated query that may be outstanding. So,for example, if the user was instructed to press 1 on a keypad tosignify that he has now left work for the day, and the input is a signalthat the 1 was pressed, then the interpretation is that the user hasleft for the day, and the appropriate action (as specified by thematching rule) is to create an “update my working hours” unit of workfor execution below (see Block 525).

After correlating the response with a query, Block 520 checks to see ifthe query to which this response corresponds has an associated timer. Ifso, then Block 515 cancels this timer. In either case, processingcontinues at Block 525, which performs the unit(s) of work (as describedin FIG. 7) to carry out the action(s) called for in the rule(s)associated with this user response. Processing for this iteration ofFIG. 5 then ends.

FIG. 6 provides logic that may be used to handle expiration of a timer.The expiration event preferably provides information about the eventthat caused the timer to be started. This expiration information isreceived at Block 600. Block 605 then determines the rules that relateto the timer, and Block 610 performs the actions specified by theserules (as described in FIG. 7). The processing of FIG. 6 then ends forthis iteration.

FIG. 7 depicts logic used in preferred embodiments to perform theactions referred to in FIGS. 4-6. Block 700 builds one or more units ofwork, as appropriate. The logic of Blocks 705-750 then performs each ofthese work units, and is preferably implemented as a switch operationthat checks for and processes each type of work unit. Block 705 checksto see if the unit or work is of the form “invalidate (or validate)context source XYZ until date/time”. If so, then Block 710 sets thevalidity attribute of the indicated context source to “invalid” or“valid”, as appropriate, until an ending time (or for a duration oftime) specified by the action.

If Block 705 has a negative result, then Block 715 tests to see if theaction was to invalidate (or validate) a context source until furthernotice. If so, Block 720 sets the validity attribute for that source to“invalid” or “valid”, as appropriate.

If neither Block 705 or Block 715 is true, control reaches Block 725,which tests to see if the unit of work calls for updating a contextsource (e.g., to update the specified working hours and/or scheduledevents on this user's calendar). If this test has a positive response,then the corresponding update of the context source (as indicated by thematching rule) is performed (Block 730).

If the unit of work still does not match any of the tests, controlreaches Block 735, which checks to see if the unit of work calls forsending a notification to the user or to the context supplier. If so,then the notification is sent at Block 740.

Finally, Block 745 checks to see if the unit of work calls forperforming some other type of work. If so, then that work is performedat Block 750. For example, a task might be started, or a service mightbe requested, as indicated in FIG. 7.

Following completion of Blocks 710, 720, 730, 740, or 750, controltransfers to Block 755. In addition, if the unit of work does not matchany of the tests, then the input is preferably ignored, and controltransfers to Block 755.

Block 755 tests whether there are any more units of work to beprocessed. If so, then control returns to Block 705; otherwise, theprocessing of FIG. 7 exits for this invocation.

Rule-based systems and context services are known in the art. Usingrules to detect and resolve conflicts in information from multiplecontext receivers, as disclosed herein, is not known. Many systems areknown in the art that provide and use location information. IBM's TempusFugit project, for example, uses both calendar information and locationinformation for time-based purposes, such as predicting when a personmay arrive at a meeting. (See http://time.almaden.ibm.com for moreinformation on Tempus Fugit.) No systems are known to the inventors thatuse context information to update an updateable context source (such asby adjusting scheduled calendar events and/or working hours upondetecting context conflicts), or to invalidate a context source basedupon a detected conflict, or to notify a context supplier that it isproviding erroneous data.

As has been demonstrated, the present invention discloses advantageoustechniques for detecting conflicts in context information from varioussources, and that information may be used to automatically update one ormore context sources and/or to invalidate (for a period of time or untilfurther notice) input from one or more context sources. Or, the updatemay be made after querying the user for input. Rules are preferably usedto specify how conflicts for each user (and/or for a particularorganization or other user category) are to be resolved. Updating thecontext source is particularly useful for electronic calendars, andinvalidating the source data is particularly useful for lost, forgotten,misplaced, or loaned devices. When using the present invention, moreaccurate data will be reflected on users' calendars with less effortrequired of those users, enabling other individuals to more accuratelydetermine where the calendar owner is and his availability at a point intime. Additionally, calendar-based tools (such as those disclosed in therelated U.S. patents for responding to incoming events such as voicemail and for using calendar events to update status in otherapplications), vacation planners, and so forth will have more accuratecalendar data with which to work. Location-based applications and othercontext-aware applications will have more accurate context informationfrom sources that are updateable and will have better knowledge of whencontext data is valid. Suppliers of context information will be notifiedwhen their service is providing erroneous context information, allowingthem to correct these errors.

As will be appreciated by one of skill in the art, embodiments of thepresent invention may be provided as methods, systems, or computerprogram products. Accordingly, the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment, oran embodiment combining software and hardware aspects. Furthermore, thepresent invention may take the form of a computer program product whichis embodied on one or more computer-readable storage media (including,but not limited to, disk storage, CD-ROM, optical storage, and so forth)having computer-readable program code embodied therein.

The present invention has been described with reference to flowchartillustrations and/or flow diagrams of methods, apparatus (systems), andcomputer program products according to embodiments of the invention. Itwill be understood that each block of the flowchart illustrations and/orflow diagrams, and combinations of blocks in the flowchart illustrationsand/or flows in the flow diagrams, can be implemented by computerprogram instructions. These computer program instructions may beprovided to a processor of a general purpose computer, special purposecomputer, embedded processor, or other programmable data processingapparatus to produce a machine, such that the instructions, whichexecute via the processor of the computer or other programmable dataprocessing apparatus, create means for implementing the functionsspecified in the flowchart and/or flow diagram block(s) or flow(s).

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function specified in the flowchart and/or flowdiagram block(s) or flow(s).

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer-implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions specified in theflowchart and/or flow diagram block(s) or flow(s). Furthermore, theinstructions may be executed by more than one computer or dataprocessing apparatus.

While preferred embodiments of the present invention have beendescribed, additional variations and modifications in those embodimentsmay occur to those skilled in the art once they learn of the basicinventive concepts. Therefore, it is intended that the appended claimsshall be construed to include all such variations and modifications asfall within the spirit and scope of the invention.

1. A method of detecting harmony in context information usingcomputer-readable program code executed by a computer, comprising:obtaining context information gathered from a plurality of contextsources; determining, using the obtained context information, whetherharmony exists among the context sources; and if harmony is determinedto exist and any of the context sources are marked as providing invalidcontext information, applying a set of user-customizable rules todetermine whether one or more of the context sources marked as providinginvalid context information should be changed to mark that contextsource as providing valid context information.